On Thursday 21 February 2002 01:02 pm, you wrote:
> My personal goal is L3, which I visualize as a FreeRIDE plugin. Actually,

Ah, yes, L3 wouldn't mesh very well with a drag-drop GUI builder.  I was 
thinking that you wouldn't /need/ a GUI builder, but I suppose that's naive.

> My personal favorite general purpose L3 for Java is the one built in to
> Borland's JBuilder. The graphical builder and the generated code are just
> two views of the same thing -- you can modify either one and see the
> results in the other. Most GUI builders don't let you arbitrarily modify
> the generated code, and even those that do will overwrite your mods the
> next time you use the graphical view.

I have yet to see an IDE that generated anything near usable, maintainable 
code.  Maintainability is generally guaranteed only if (a) you don't modify 
the generated code, and (b) you always use that IDE -- meaning that if you 
start with JBuilder, you're locked into it for life.

In any case, I was thinking about a /dynamic/ L3; one that doesn't /require/ 
any user intervention at all:

  class Login < CrocusPanel
    textfield :Name
    passwordfield :Password
    button :Login
  end

  class SQLQuery < CrocusPanel
    table :results
    textarea :Query
    button :Submit, :Close
    def describe_results
      set_border :etched
      set_border_title "SQL Results"
    end
  end

  class MyApplication
    def initialize
      login = Login.new
      query = SQLQuery.new

      login._Login { |button|
        if validate( button.parent._Name, button.parent._Password)
        crocus_show query
      }

      query._Submit { |button|
        query = button.parent._Query.contents
        crocus_error_dialog( "You must supply a query") & return if query.size == 0
        execute_query_and_stuff_results_into query._results
      }
      query._Close { |button| exit }
    end
  end

Ok.  Why do I like this?  Well, the GUI code is fairly transparent -- that 
is, you do don't have to write any (much?) more code than you would to
write the application without GUI itself.  

Further, you can do some reasonable assumptions about how this stuff 
should be layed out, and the places where the toolkit lays it out 
incorrectly, you can change by hand.  This is rapid prototyping, after 
all.

The layout manager takes advantage of the order in which things were 
declared to order the widgets and expose windows.  This is a reasonable 
assumption; people code GUIs as they visualize them... rarely do you see
buttons from the bottom of the panel declared at the top of the method.  
Another assumption is that if you see a label followed by a text field, 
you should place them side by side.  Other assumptions: people prefer 
square, rather than overly wide or tall windows.  People like things to 
line up.  People don't like a lot of empty space in their windows.  And 
again, if the assumptions are wrong, you force them to be otherwise by 
hand.

What I'm saying is that we require users to code only as much as they have
to. In the worst case, it'll be no worse than if we force them to lay it 
all out by hand by using a different API.  This embodies very much, to me,
both XP and Ruby.

Why DON'T I like this?  There's no separation of the model from the view.
Your GUI looks like your code (more or less).  I can't think of any other
reasons, but let me try writing a few pseudo apps using it and I'll come
up with some others.

OT: I've been thinking about writing an essay about why separation of
model from view is bad, based on the premise that OO is fundamentally an
attempt to model the world, and where in the world /isn't/ the physical
representation of something a fundamental characteristic of the something?
But until I write the paper to my satisfaction, I'll assume that the 
current theory of MVC is useful.

-- 
 |..  "I wonder if infants enjoy infancy as much as adults enjoy adultery"
<|>   -- anon
/|\   
/|    
 |         
